Rescue
Volume Number: 1
Issue Number: 10
Column Tag: Special Projects
"Rescue that Protected Basic Program!
By Mike Steiner, Sierra Vista, AZ., MacTutor Contributing Editor
In my diggings into Microsoft BASIC, I found some interesting things about how a
program is stored on disk. My ultimate aim is to be able to “crack” a protected BASIC
program; I once lost a program because I had saved it as protected and did not have an
unprotected back-up copy.
The information in this column is valid only for BASIC Version 2.0; the
discussion and program are not valid for Version 2.1. Most of the data presented in ‘MS
BASIC Tokens Explained’ in the July 1985 Mactutor do not apply to Version 2.1. Also,
the program is for a 512K Macintosh. Change the starting memory location (Peekloc)
for a 128K or 1024K Macintosh as described in ‘MS BASIC Tokens Explained.’
Each version of BASIC (Binary and Decimal) is coded so that the finder treats
them as two different creators. This, I assume, is because of the incompatabilities
between the two versions. See last month's discussion of how numbers are stored in
the two versions.
Fig. 1 How Rescuit Works
Table 1 shows the creators, file types, and ID bytes of the various files used by
Microsoft BASIC version 2.0. (See sidebar for a brief explanation of creators and
file-tpes.) The four-letter codes in parentheses on the top line of the table are the
identification of the creators of the files. The four-letter codes in the table show the
file types. The hexadecimal numbers in parentheses show the first byte (ID byte) of
the files. TEXT files do not have an ID byte.
Once a file is loaded, the ID byte tells BASIC whether the file is protected. TEXT
files do not need an ID byte because BASIC knows it is a text file and loads it in as is,
translating reserved words into their hexadecimal tokens. BASIC can load any text file
and treat it as a program listing (sometimes with curious results if the file is not a
program). Each version (binary or decimal) can load compressed and protected files
that were created only by itself. However, you can use SetFile to change the creator ID
to load a file from the ‘other’ BASIC. If you do this, I recommend changing the ID byte
with a disk zap program such as fEdit. Keep in mind that if there are any non-integer
numbers defined in the program listing, their format will not be proper for the ‘new’
creator.
Protected programs, in addition to being having a unique TYPE and ID byte, are
encyphered. It appears that this encyphering in only in the Macintosh version of
Microsoft BASIC; friends with CP/M and MS DOS versions have not encrypted files
with their versions of Microsoft BASIC. I have not yet been able to decypher these
files; I have however, devised an interesting solution!
Following is a discussion of how you can prevent losing access to protected
programs. The method discussed will not work on programs already protected; it will,
however, give you a ‘back door’ into future programs. It works because when a
protected program is loaded, it is decyphered and resides in memory as if it had been
loaded from a text or compressed file. However, LIST, PEEK, and a slew of other
commands are disabled in the command window. These commands have not been
disabled from running from within the program, and that is what allows us to recover
the file.
Listing 1 is a subprogram called "rescueit" which may be appended to any
program prior to saving it as protected. Save rescueit as a TEXT file and MERGE it to
your program. To use it, type the name of the subprogram in the command window,
answer one question, and wait until it says that it is finished. (The name of the
subprogram is in effect a password, so I strongly recommend that you change it to a
name that only you know; otherwise anyone who knows it can recover your program.)
Your program will be saved as a file called “Ressurected.”
Rescueit asks whether you are using Binary or Decimal BASIC. It then opens a
file called “res” for output and then PRINTs one byte (the ID byte for a compressed
program in the version of BASIC you are using) to the file. It then PEEKs the program
in memory and PRINTs it to res, one byte at a time. It then PRINTs five zeroes at the
end of the file. Read ‘MS BASIC Tokens Explained’ to see why this is necessary. After
closing res, rescueit renames “res” as “Ressurected” and changes the filetype from
TEXT to MSBC or MSBB, as appropriate. Then it prints “finished..” on the screen and
exits to the desktop. Calling a sub-program from the command window sometimes
scrambles pointers and causes memory problems. By exiting to the finder, these
problems are avoided. The next step is to re-enter BASIC, load “Ressurected” using
the Standard File and save the program. The program is now saved in compressed
mode, ready to run or be edited. This last step sets the creator. If this step is omitted,
the program will still load and run, but only from within BASIC; the finder will not
recongnize an application to run the program if it is double-clicked, and the file will
have the generic document icon. The only difference between ressurected and the
original program is that ressurected has an extra blank line at the end of the listing. If
you understand how BASIC stores programs in memory, you should be able to figure
out why this is so. The reason is printed in a question / answer session at the end of
this article.
Use of the program is fairly straightforward. Assuming that you already have
rescuit on your disk (Remember to save it as a text file, not as a compressed
program.), write your program and save it as a text or compressed file. (Don't forget
to always keep a backup file!) In the command window, type “Merge "rescueit".” This
will cause rescueit to be appended to the end of your program. Then choose “Save
As” from the File menu. Save your program (with rescueit appended) as a protected
program. Now, if you ever lose your backup and need to recover the protected file,
load BASIC and open the protected file. Within the command window, type resuceit (or
the name to which you renamed the sub-program). The routine will execute, and when
it ends will tell you that it is finished and return to the desktop. Next, set the creator
as described above. Whenever you use rescueit, start with the Macintosh turned off.
As discussed in ‘MS BASIC Tokens Explained,’ if another application has been run
before BASIC, sometimes BASIC programs do not load at the same memory location.
Rescueit always assumes that the program loads at the same point. Illustration 1 is a
brief schematic of the rescueit process.
File Types and Creator Bytes
File-type and creator (also called file-type and creator flags) are four-letter
abbreviations that show the file type and which application generated the file. An
application (i.e. a program that can be run by double-clicking it's icon on the desktop)
is a file that always has the file-type APPL. All other files are known as ‘Documents’
and may have any file-type that the programmer chooses.
Applications without a defined icon use the generic application icon (the
diamond-shaped paper with a hand writing on it). Documents without a defined icon
use the generic document icon (a piece of blank paper with the upper right corner
folded down).
The finder uses the file type and creator flags to know which document files can
be loaded by a given application. A document is linked to it's creator by the creator
flag. When a document and a program have the same creator, the finder knows to
launch that program when you double click on the document icon; once the program is
launched, the finder tells it to open the document. The file type flag has a number of
purposes. The most common is to assign an icon to the file. All the desk-top icons used
by a program are stored in it's ICN# resource. The finder uses the type and creator
flags to assign the correct icon to the file. (However, for ducument files, a bit in the
application called the bundle bit must be set to 1; otherwise, the link is not
established.) Also, the Standard File (which contains the list of documents that you can
open when you choose Open from the File menu within a program) uses the file type to
determine which files may be opened. These files are not restricted to those created by
the application; for example, Microsoft Word can open files created by Apple's
Macwrite. However, you cannot open a Macwrite document with Word by
double-clicking the document icon; you can only do it from within Word via the
Standard File.
Two interesting features of Microsoft BASIC are that you can specify file types
when loading a file from within a program by use of the FILE$(1) function; by using
the NAME command, you can change the file-type of a file on the disk. Rescueit makes
use of this latter feature to change the rescued program from a TEXT file to a BASIC
compressed file; this step is necessary because the file is generated in the compressed
format, but saved as a TEXT file.
So far as I have been able to determine, there is no way for a Microsoft BASIC
program to determine which version of BASIC it is using. The prefix byte exists only
on the disk, and is not stored in memory; FILES$(1) can read the file type, but not the
creator; NAME likewise can change only the file type and name. Does anyone know how
to read or set the creator of a file from within MS BASIC? MacTutor will pay $50 to
the first submission that shows how to do it.
Table 1
Microsoft BASIC 2.0 Creator and File Type Codes
Mode Binary (MSBB) Decimal (MSBA)
Text TEXT TEXT
Compressed MSBC (F9) MSBB (FB)
Protected MSBD (F8) MSBP (FA)
Listing 1 - Rescueit
REM }|{ Marker for end of main program - don't change!!
SUB rescueit STATIC: REM Change the name “rescueit” of sub-program
for password protection
prefixbyte(1) = &HF9:prefixbyte(2) = &HFB
filetype$(1) = "MSBC":filetype$(2) = "MSBB
Peekloc(1) = 66999!: Peekloc(2) = 77001!
WINDOW 1,,(100,100)-(400,200),2
TEXTFONT 0
PRINT " Which version of BASIC are you using?
TEXTFONT 1
BUTTON 1,1,"Binary",(35,40)-(95,65)
BUTTON 2,1,"Decimal",(170,40)-(240,65)
WHILE DIALOG (0)<>1:WEND
buttonpressed = DIALOG (1)
Peekloc = Peekloc( buttonpressed)
WINDOW 1,"rescuit",(2,39)-(508,338),1
OPEN "res" FOR OUTPUT AS #1
PRINT#1,CHR$(prefixbyte( buttonpressed));
rescue1:
peekloc = peekloc +1
IF PEEK (peekloc) = &HAF THEN IF PEEK (peekloc+1) = &H20 AND PEEK
(peekloc+2) = ASC ("}") AND PEEK (peekloc+3) = ASC ("|") AND
PEEK (peekloc+4 ) = ASC ("{") THEN rescue2: REM Find marker
PRINT #1, CHR$ (PEEK (peekloc));
GOTO rescue1
rescue2:
FOR j = 1 TO 4
PRINT #1,CHR$(&H0);
NEXT j
CLOSE #1
NAME "res" AS "Resurrected", filetype$( buttonpressed)
CALL TEXTSIZE (127)
PRINT: PRINT "Finished..";
SYSTEM
END SUB
Q: "Why does rescuit add a line feed to the end of a file?
A: When rescueit (or any other file) is merged to a program, it is appended to the
end of the program, starting on a new line. This generates a carriage return after the
last line of the program. Then when rescueit runs, it looks for the REM line that
starts the rescueit routine, and saves the program up to the last byte before the REM.
This last byte is the carriage return that was inserted when rescueit was merged. A
carriage return at the end of a program is treated by BASIC as a blank line.
For What It's Worth Dept.
Peter Wollschlaeger of Hildeseim, West Germany, sent in this little gem. Try it,
you'll like it! Peter says "...the most information I ever got for a Mac programmer like
me in Macworld was an ad to subscribe to MacTutor!" Peter also reports that trying to
run the MDS Editor under Finder version 3.3 bombs. Update to 4.1 Peter. Then your
only problem will be missing icons occasionally! (See top column right.)
program Bugged;
var
r : rect;
left, top, right, bottom : integer;
icon1, icon2, width : integer;
begin
left := 10;
top := 10;
right := 40;
bottom := 40;
width := right - left + 10;
icon1 := 1;
icon2 := 257;
showdrawing;
setrect(r, left, top, right, bottom);
ploticon(r, geticon(icon1));
setrect(r, left + width, top, right + width, bottom);
ploticon(r, geticon(icon2));
end.